Securely recovering a computing device

ABSTRACT

A method and an apparatus for establishing an operating environment by certifying a code image received from a host over a communication link are described. The code image may be digitally signed through a central authority server. Certification of the code image may be determined by a fingerprint embedded within a secure storage area such as a ROM (read only memory) of the portable device based on a public key certification process. A certified code image may be assigned a hash signature to be stored in a storage of the portable device. An operating environment of the portable device may be established after executing the certified code.

FIELD OF INVENTION

The present invention relates generally to electronic security. Moreparticularly, this invention relates to recover a computing devicesecurely.

BACKGROUND

As more and more computing devices are being used in people's dailylife, security has become a widespread concern for users and contentproviders. Viruses, worms, Trojan horses, identity theft, software andmedia content piracy, and extortion using threats of data destructionare rampant. Usually, these attacks involve installing and executingmalicious software codes to expose access to device resources that wouldotherwise be private to the system, the content provider, the user or anapplication.

For example, a hacker program when running in consumer computing devicesdeveloped to play audio/video content, such as Hollywood movies ormusic, could potentially allow the cracking of the encryption used tosecure the A/V content. Therefore, high levels of security are usuallyrequired for such devices.

An operating system may provide some security features to guard againstsuch attacks. However, the security features of an operating systemoften fail to keep up with new attacks occurring on a daily basis.Moreover, when booting a computing device, security features may not yetbe initialized and are vulnerable to bypass and/or tampering.

Another way to guard against these attacks is to completely seal acomputing device from installing and/or running any additional softwareafter shipped out from manufacturers. Such a strict measure, however,severely limits the capabilities and the flexibilities of the underlyingcomputing device. Not only does it make upgrading a computing devicecostly and difficult, it is not able to take advantage of increasingnumber of applications which do require downloading and running softwarecodes from outside the device. In addition, the rapid technologyadvancement usually renders the applications or functionalitiesoriginally built inside a computing device obsolete within a very shortperiod of time.

Therefore, current security measures do not deliver a robust solution toprotect applications and content inside a computing device, while at thesame time providing the flexibility to update the software and orfirmware for the device.

SUMMARY OF THE DESCRIPTION

A method and apparatus for establishing an operating environment for adevice by certifying a code image received from a host over acommunication link are described herein. The code image may be digitallysigned. Certification of the code image may be determined by afingerprint embedded within a ROM (read only memory) of the device basedon a public key certification process. A certified code image may beassigned a hash signature to be stored in a storage of the device. Anoperating environment of the device may be established after executingthe certified code image.

In an alternative embodiment, a recovery process may be performed torecover a code image immediately after a failure to verify and executethe code image to load and verify another code image. The device maycommunicate with a host via a communication link to signal that thedevice is in a recovery mode to receive from the host a new executableimage corresponding to the failed code image. The new code image may beverified using a digital certificate embedded within the secure ROM ofthe device. The new code image may be executed upon being successfullyverified. Optionally, the verified new code image may be stored in themass storage of the device to replacing the failed code image.

In an alternative embodiment, in response to successfully authenticatinga portable device over a communication link based in part on a uniqueidentifier (ID) embedded within a secure ROM (read-only memory) of thedevice, the device may be determined to be in a recovery mode as aresult of a failure to initialize an operating environment of thedevice. An executable image digitally signed by a signature may beretrieved from a server over a network. The executable image may bedelivered to the device over the communication link. The device mayverify the signature of the executable image using a digital certificateembedded with the secure ROM. The verified executable image may beloaded in a main memory of the device to establish the operatingenvironment for the device.

Other features of the present invention will be apparent from theaccompanying drawings and from the detailed description that follows.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and notlimitation in the figures of the accompanying drawings, in which likereferences indicate similar elements and in which:

FIG. 1 is a block diagram illustrating one embodiment of systemcomponents for secure booting;

FIG. 2 is a block diagram illustrating one embodiment of systemcomponents executing secure booting;

FIG. 3 is a flow diagram illustrating one embodiment of a process toperform secure booting;

FIG. 4 is a flow diagram illustrating one embodiment of a process togenerate a signature from a code image based on an UID (UniqueIdentifier) and a seed string;

FIG. 5 is a block diagram illustrating one embodiment of networkconnections for a host to securely boot a device;

FIG. 6 is a flow diagram illustrating an embodiment of a process tosecurely recover an operating environment from a host to a device;

FIG. 7 is a state diagram illustrating an embodiment of a process toperform minimum secure recovery of an operating environment from a hostto a device;

FIG. 8 is a flow diagram illustrating one embodiment of a process tosecurely restore software components from a host to a device;

FIG. 9 is a flow diagram illustrating one embodiment of a process tosecurely update an application from a host to a device;

FIG. 10 is a flow diagram illustrating one embodiment of a process forexecuting unverified code image;

FIG. 11 illustrates one example of a typical computer system which maybe used in conjunction with the embodiments described herein.

FIG. 12 shows an example of a data processing system which may be usedwith one embodiment of the present invention

DETAILED DESCRIPTION

A method and an apparatus for secure booting of a computing device aredescribed herein. In the following description, numerous specificdetails are set forth to provide thorough explanation of embodiments ofthe present invention. It will be apparent, however, to one skilled inthe art, that embodiments of the present invention may be practicedwithout these specific details. In other instances, well-knowncomponents, structures, and techniques have not been shown in detail inorder not to obscure the understanding of this description.

Reference in the specification to “one embodiment” or “an embodiment”means that a particular feature, structure, or characteristic describedin connection with the embodiment can be included in at least oneembodiment of the invention. The appearances of the phrase “in oneembodiment” in various places in the specification do not necessarilyall refer to the same embodiment.

The processes depicted in the figures that follow, are performed byprocessing logic that comprises hardware (e.g., circuitry, dedicatedlogic, etc.), software (such as is run on a general-purpose computersystem or a dedicated machine), or a combination of both. Although theprocesses are described below in terms of some sequential operations, itshould be appreciated that some of the operations described may beperformed in different order. Moreover, some operations may be performedin parallel rather than sequentially.

The term “host” and the term “device” are intended to refer generally todata processing systems rather than specifically to a particular formfactor for the host versus a form factor for the device.

In one embodiment, secure booting a device may be designed to ensurecritical resources within the device will be protected in an operatingenvironment. In the mean time, secure booting a device may provide aflexibility to allow software running inside the device to be updatedand installed under different policies and procedures without requiringunnecessary management, material and/or performance costs. In oneembodiment, the security of booting a device may be performed by thecode and data stored inside a secure storage area such as a ROM (ReadOnly Memory), also referred to as a secure ROM, integrated togetherwithin the device. The content of a secure ROM may be stored during amanufacturing stage of the device. The secure ROM may be associated witha UID (Unique Identifier) of the device, which uniquely identifies thedevice. A trust of a software code running in the device may be rootedfrom a code image signed through the secure ROM based on the UID.

According to one embodiment, the secure ROM of a device may include afingerprint of a root certificate of a trusted entity. A code imagecertified through the trusted entity may be trusted to be executed inthe device according to a certification process via the secure ROM basedon the fingerprint. In one embodiment, secure booting the device mayrecover trusted software codes when coupled with the trusted entityaccording to the secure ROM. The secure ROM may extend a trust to a codeimage certified through the fingerprint based on the device UID stored.In one embodiment, the secure ROM may allow application softwarerestoration by certifying a code image downloaded from an externalconnection. In another embodiment, the secure ROM may force cleaning upuser data stored inside the device by a trusted software code downloadedthrough external connection.

FIG. 1 is a block diagram illustrating one embodiment of systemcomponents for secure booting. System 100 may reside in one or morechips inside a device. In one embodiment system 100 may include a chip105 coupled with a memory component 103. Chip 105 may also include a RAM(Random Access Memory) component 111, such as an SRAM (Static RandomAccess Memory) or an EDRAM (Embedded Dynamic Random Access Memory). Acode image may be loaded into the memory component 103 prior to beingexecuted by the device. When executed, a code image may enable a userapplication, a system application, and/or an operating environment (e.g.operating system) for the device that supports the user or systemapplication. In one embodiment, memory component 103 includes DDR(Double Data Rate) memory. Chip 105 may include a ROM 113 storing codes115 and associated data 117. Codes 115 may include implementation of SHA(Secure Hashing Algorithm) hashing functions such as cryptographic hashfunctions SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. Additionally,codes 115 may include implementations of data encrypting algorithms suchas AES (Advanced Encryption Standard) encryption. In one embodiment,codes 115 may cause hardware initialization for the device to support aconnection or communication interface such as USB (Universal SerialBus). Codes 115 may include instructions to change the clock rate of thedevice. Note that throughout this application, SHA and AES are utilizedas examples for the illustration purposes only, it will be appreciatedthat other hashing and/or encryption techniques may also be utilized.

In one embodiment, codes 115 may cause loading a code image into adevice memory such as memory component 103 or RAM 111. A code image maybe loaded from a storage component 109 coupled with the chip 105. Thestorage component 109 may be a flash memory, such as a NAND flash, a NORflash, or other mass storage (e.g., hard disk) components. In anotherembodiment, a code image may be loaded though a connection interface 101from a source external to the device. The connection interface 101 maybe based on a USB connection, an Ethernet connection, or a wirelessnetwork connection (e.g., IEEE 802.1x), etc. In one embodiment, codes115 may cause storing a code image from a device memory into the storagecomponent 109 after verifying the code image includes only trustedcodes.

Before the device may start executing the code image loaded in thedevice memory, codes 115 may perform verification operations on theloaded code image to ensure the code image could be trusted. In oneembodiment, codes 115 may verify a loaded code image according to dataincluded in the chip 105, such as the data section 117 inside the ROM, aUID 119 and/or a GID (Global Identifier) 121. UIDs 119 may be unique foreach device. In one embodiment, all devices are associated with a singleGID 121. In one embodiment, a GID may be used to encrypt a code image toprevent code inspection. Data section 117 of the ROM 113 may store afingerprint 123 based on a signature from a trusted entity such as apublic key certificate. In one embodiment, separate devices may includefingerprints 123 based on the same trusted entity.

FIG. 2 is a block diagram illustrating one embodiment of systemcomponents executing secure booting. System 100 may load an LLB (LowLevel Boot) code image 229 from storage component 109 into RAM 111 asLLB 225. LLB 225 may be related to long term power management of thesystem 100. In one embodiment, LLB 225 may include an identification ofthe version of system 100. Code image LLB 225 may be loaded based onexecution of codes 115. In one embodiment, code image LLB 229 may bestored from RAM 111 based on code image LLB 225 via execution of codes115.

Code image iBoot 227, according to one embodiment, may be loaded intomemory component 111 from storage 109 based on code image iBoot 231according to execution of LLB 225. Code image iBoot 231 may causehardware initialization for an operating system that provides anoperating environment for the device housing system 100. A device mayenter an operating environment after a successful booting. An operatingenvironment may support various user and/or system applications runningin the device. In one embodiment, code image iBoot 231 may enable massstorage components of the device, initialize graphic components for userinterface, and/or activate screen components for the device, etc. Codeimage iBoot 231 may be stored from RAM 111 based on code image iBoot 227via execution of code image LLB 225.

In one embodiment, code image Kernelcache 223 may be loaded from storage109 to memory 103 based on code image Kernelcache 233. Code imageKernelcache 223 may be part of the kernel of an operating system tosupport the operating environment for the device. In one embodiment,code image Kernelcache 223 causes a kernel and operating systemcomponents 235 to be loaded into memory 103 from storage 109. Operatingsystem components may include user applications, libraries, graphic userinterface components, and/or user data 235. User data may include music,images, videos or other digital content associated with a user of thedevice. For example, such user data may be DRM (digital rightsmanagement) compliant data having restricted usages. Code imageKernelcache 223 may enable loading the kernel and the operating systemcomponents 235 into memory 103. In one embodiment, code imageKernelcache 223 may cause a verification process to ensure the kernel istrusted before being executed in memory 103. In another embodiment, codeimage Kernelcache 223 may cause a verification process to ensure anoperating system component 235 is trusted before being executed inmemory 103. Code image Kernelcache 223 may be executed to determine anoperating system component 235 is trusted based on LID 119 orfingerprints 123. In one embodiment, code image Kernelcache 223 maycause decryption of an operation system component 235 in memory 103according to GID 121. In one embodiment, code image Kernelcache 223 maybe executed to store operating system components 235 from memory 103into storage 109. Code image Kernelcache 223 may enable encryptingoperating system components 235 before being stored in the storage 109.

In one embodiment, UID 119 may be accessible to some operating systemcomponents running in a privileged mode. The kernel of the operatingsystem may deny or approve an application to access UID 119 by anapplication depending on whether the application is running in aprivileged mode. In one embodiment, the kernel of the operating systemmay determine whether an application can be run in a privileged modebased on whether the corresponding code image of the applicationincludes a properly signed signature. A DRM (Digital Right Management)system may be running in a privileged mode to control access to userdata of the operating system components 235 based on LID 119. Anapplication may access user data through a DRM system. In someembodiments, network utilities of the operation system may beprivileged. Network utilities may enable the device to interconnect withoutside resources though an interface chip, such as base band chip. Inanother embodiment, virus protection software may be provided by theoperating system to run in a privileged mode.

Thus, any software components that will be running within the systemmust be verified or authenticated prior to the execution, unless thesoftware components satisfy certain predetermined conditions (e.g.,provided by a trust vendor or during certain circumstances such asmanufacturing of the device or testing of the software components). Inone embodiment, the settings of a secure storage area in the system maybe associated with a predetermined condition. As a result, any data suchas DRM compliant data would not be accessed or compromised withoutproper verification or authentication.

FIG. 3 is a flow diagram illustrating one embodiment of a process toperform secure booting. For example, process 300 may be performed bysystem 100 of FIG. 1. During a booting process of a device, according toone embodiment, the processing logic of process 300 may locate a codeimage from within the device by executing instructions in a ROM chip atblock 301. The instructions may be read from a code section of the ROMchip as in codes 115 of FIG. 1. The code image may be stored in a memorycomponent or a storage component of the device. A memory component maybe a RAM. A storage component may be a flash memory or a mass storagedevice attached to the device. In one embodiment, if the code imagecould not be located, the booting process may be interrupted and thedevice may enter a DFU (Device Firmware Upgrade) mode at block 309. Ifthe code image is located successfully, according to one embodiment, theprocessing logic of process 300 may load the code image into a memory atblock 303. In another embodiment, the code image may already been loadedin the memory when located.

At block 305, according to one embodiment, the processing logic ofprocess 300 may verify whether the loaded code image could be trustedbased on a UID associated with the device such as UID 119 of FIG. 1. Theprocessing logic of process 300 may extract a header value from the codeimage. The location of the header value inside the code image may bepredetermined. In one embodiment, the header value may be extractedbased on a preset attribute in an attribute value pair inside the codeimage. The header value may include a signature value signed over thecode image according to the UID of the device through well-known hashingand encryption algorithms. In one embodiment, the processing logic ofprocess 300 derives another signature value from the code imageaccording to the UID through the same well-known hashing and encryptionalgorithms at block 305. The processing logic of process 300 may comparethe derived signature value and the extracted signature value to verifywhether the code image is trusted. In one embodiment, the verificationmay be successful 307 if the derived signature value and the extractedsignature match with each other. Otherwise, the verification may fail.If the verification is not successful 307, the processing logic ofprocess 300 may cause the device to enter a DFU mode at block 309. Inone embodiment, the processing logic of process 300 may remove the codeimage from the memory before the device enters the DFU mode at block309.

If the verification is successful, the processing logic of process 300may execute the code image at block 311. In one embodiment, the codeimage may be an LLB, an iBoot or a Kernelcache as shown in 225, 227 and223 in FIG. 2. The processing logic of process 300 may perform bootingoperations for the device at block 311. Booting operations may includeproduct identifications, starting device power management, enabling massstorage components, initializing graphic components for user interface,activating screen components and/or device hardware initialization, etc.In one embodiment, booting operations may include loading an operatingsystem to the memory including a kernel and certain operating systemcomponents such as shown in 235 of FIG. 2. The processing logic ofprocess 300 may attach a trust indicator to a trusted code image in thememory to indicate a successful verification. In one embodiment, a codeimage associated with a trust indicator located in a memory may beexecuted as a trusted code without verification. At block 313, theprocessing logic of process 300 may determine if the device iscompletely booted. If the device is completed booted, the device maybecome operational and enter a normal operational mode at block 315. Inone embodiment, a Kernelcache 223 may start a user application runningin a user mode after the device enters a normal operation. Anapplication running in a user mode may not access device hardwarerelated information such as UID 119 and GID 121 of FIG. 2. The devicemay enter a DFU mode if a booting operation fails at block 313.

At block 317, according to one embodiment, the booting process maycontinue when the processing logic of process 300 determines the devicebooting process is not complete at block 313. The processing logic ofprocess 300 may locate another code image at block 313 based onexecuting the current code image. In one embodiment, executing codeimage LLB may locate code image iBoot as shown in FIG. 2. In anotherembodiment, executing code image iBoot may locate code image Kernelcacheas shown in FIG. 2. In some embodiments, executing code imageKernelcache may locate code images including the kernel and operatingsystem components as shown in FIG. 2. The processing logic of process300 may loop back to block 319 to proceed on the booting processaccording to the result of locating the next code image at block 317.

FIG. 4 is a flow diagram illustrating one embodiment of a process togenerate a signature from a code image based on an UID ad a seed string.For example, process 400 may be performed by a system as shown inFIG. 1. In one embodiment, the processing logic of process 400 performsa hashing operation 409 over a code image 411 i such as LLB 225, iBoot227 or Kernelcache 223 shown in FIG. 2. The hashing operation may bebased on SHA (Secure Hash Algorithm) hashing functions such ascryptographic hash functions SHA-1, SHA-224, SHA-256, SHA-384, andSHA-512. In one embodiment, hashing operation 409 may produce a keystring 413. Key string 413 may have a length of 20 bytes. In oneembodiment, the processing logic of process 400 may perform anencrypting operation at block 403 to generate a signature 405 based onkey string 413, UID 401 and seed string 407 associated with a device. Inone embodiment, the encrypting operation may be based on an AES(Advanced Encryption Standard) algorithm at block 403. The processinglogic of process 400 may truncate key string 413 at block 403, such asdiscarding 4 out of 20 bytes of key string 413. In one embodiment, theAES algorithm at block 403 is based on 16 bytes. UID 401 may be storedwithin the device as UID 119 shown in FIG. 1. Seed string 407 may begenerated through a seed generating function based on the device. In oneembodiment, seed string 407 may be the same each time the seedgenerating function is applied for the same device.

FIG. 5 is a block diagram illustrating one embodiment of networkconnections for a host to securely boot a device according to the systemof FIG. 1. In one embodiment, a device may enter a DFU mode for bootingby connecting to a host. A device may be forced to enter a DFU modebased on an initiation from a user. In one embodiment, a device mayenter a DFU mode in response to a user performing a predetermined actionsuch as pressing a button of the device. A user may request a device toenter a DFU mode for performing system management tasks for the device,including, for example, cleaning up user data, upgrading hardwaredrivers, upgrading user applications, and/or installing newapplications, etc. A device may automatically enter a DFU mode when thedevice fails to hoot in at least one stage of the booting sequence, suchas shown at block 309 of FIG. 3. Alternatively, a device may enter a DFUmode when the operating system encounters an abnormality during normaloperation such as when a corrupted data or damaged software componentsare detected.

According to one embodiment, network 500 may include a device 501coupled with a host 503. Device 501 may be a media player such as, forexample, an iPod from Apple Computer Inc. running restoring daemonapplication to restore operating system components from the coupled host503. Device 501 may be coupled with host 503 through a connectioninterface supporting TCP/IP protocols. The connection interface may bebased on USB, a wireless network or an Ethernet, etc. In one embodiment,host 503 may be a Mac or Windows based computer running applicationsoftware such as, for example, an iTune application from Apple ComputerInc. Host 503 may be connected to a central server 507 through thenetwork 505 such as wide area network (e.g., Internet) or local areanetwork (e.g., Intranet or peer-to-peer network). In one embodiment,central server 507 may be based on a publicly accessible web server.Alternatively, server 507 may be an Intranet or local server.

FIG. 6 is a flow diagram illustrating an embodiment of a process tosecurely recover an operating environment from a host to a device. Forexample, process 600 may be performed by systems as shown in FIGS. 1and/or 5. In one embodiment, the processing logic of process 600 maysend a status to a host computer indicating a device being in a recoverymode at block 601. The device may enter the recovery mode in response toa failure to verify a code image. The host computer may be coupled to adevice performing process 600 as shown in FIG. 5. In one embodiment, thestatus may include a product ID and/or a vendor ID. The host computermay prepare a code image to recover the connected device based on thereceived status. In one embodiment, the code image may be retrieved froma central server computer by the host computer connected over a networksuch as network 505 as shown in FIG. 5. At block 603, according to oneembodiment, the processing logic of process 600 may receive the codeimage from the host computer into a memory component of a device, suchas memory 103 as shown in FIG. 1. The processing logic of process 600may receive an instruction from the host computer to execute thereceived code image at block 605. In one embodiment process 600 may becontrolled by recovery software running on the host computer, such asiTune running in a MAC based computer.

According to one embodiment, at block 607, the processing logic ofprocess 600 may extract a certificate accompanying the code imagereceived in the memory of the device. The code image may be a LLB, aniBoot and/or a Kernelcache as shown in FIG. 2. The code image may beencrypted according to public key cryptography such as RSA (Ralph ShamirAdelman) public key cryptography. The certificate may include a keybased on X.509 standard. At block 609, the processing logic of process600 may verify the certificate according to the code stored in a secureROM of the device such as code 115 shown in FIG. 1. In one embodiment,the processing logic of process 600 may certify a chain of certificatesto verify the extracted certificate with a root certificate as the lastcertificate in the chain. The processing logic of process 600 mayretrieve certificates from the connected host computer. In oneembodiment, the root certificate may be verified based on thefingerprint stored in a secure ROM of the device, such as fingerprint123 as shown in FIG. 1. The root certificate may be issued by AppleComputer Inc. If the verification fails, the processing logic of process600 may return the device back to DFU mode to be recovered at block 613.

If the certificate from the code image is successfully verified, theprocessing logic of process 600 may continue the recovery process atblock 615 to decrypt the code image based on the key included in theverified certificate. At block 617, the processing logic of process 600may derive a hash signature from the code image based on a UID stored ina secure ROM of the device, such as UID 119 as shown in FIG. 1. In oneembodiment, the hash signature may be obtained, for example, accordingto the process as shown in FIG. 4. At block 619, the processing logic ofprocess 600 may sign the derived signature into the code image. In oneembodiment, the derived signature may be signed as a header value of thecode image. The processing logic of process 600 may store the signedcode image into a storage of the device at block 621, such as, forexample, storage 109 shown in FIG. 1. In one embodiment, a signed codeimage may be stored to repair another code image failed to be verifiedin the device. In one embodiment, the code image may be executed beforebeing stored into a storage of the device. In another embodiment, thecode image may be stored into the storage of the device after beingsuccessfully executed.

FIG. 7 is a state diagram illustrating an embodiment of a process toperform secure recovery of an operating environment from a host to adevice. For example, states 700 may represent certain operating statesof systems as shown in FIGS. 1 and/or 5. In one embodiment, a device mayenter an initial state Boot 701 to start a boot process. Instructionsstored in a secure ROM of the device may be executed during state Boot701. In one embodiment, during state Boot 701, a low level boot programsuch as LLB 229 shown in FIG. 2 may be located within the device. Thelow level boot program may be located and loaded into a memory componentof the device. In one embodiment the located low level boot program maybe verified to be a trusted code image according to a process such asdescribed at block 305 of FIG. 3. If the low level boot program issuccessfully located and verified, state 700 may enter state LLB 703from state Boot 701 according to transition Success 711. Otherwise,according to one embodiment, state 700 may enter state Recovery1 717through transition DFU 713 as the device enters a DFU mode.

During state Recovery1 717, the device may be coupled with a hostcomputer to perform a recovery process such as shown in FIG. 5. In oneembodiment, the device may publish a status based on state Recovery1717. The host computer may send a code image corresponding to the statusreceived from the device. In one embodiment, the code image may be anLLB 229 as shown in FIG. 2. The device may perform a chain ofcertifications to verify the received code image is trusted based on aUID and a fingerprint stored inside a secure ROM of the device such asUID 119 and fingerprints 123 of FIG. 1. The chain of certifications maybe performed based on a process similar to process 600 at block 609 inFIG. 6. If the code image is successfully loaded and verified, in oneembodiment, the state of the device may be transitioned from stateRecovery1 717 to state LLB 703 through transition Load 715.

In one embodiment, during state LLB 701, the device may execute theverified low level boot program (e.g., LLB or low level library asdescribed above) to locate another boot image such as iBoot 231 shown inFIG. 2 within the device. The boot image may be located and loaded intoa memory component of the device during state LLB 701. In oneembodiment, the boot image may be verified to be a twisted code imageaccording to a process such as described at block 305 of FIG. 3. If theboot image is successfully located and verified, state 700 may enterstate iBoot 705 from state LLB 703. Otherwise, according to oneembodiment, state 700 may enter state Recovery2 719 as the device entersa DFU mode.

During state Recovery2 719, the device may be coupled with a hostcomputer to perform a recovery process such as shown in FIG. 5. In oneembodiment, the device may publish a status based on state Recovery2719. The host computer may send a code image corresponding to the statusreceived from the device at state Recovery2 719. In one embodiment, thecode image may be an iBoot 231 as shown in FIG. 2. The device mayperform a chain of certifications to verify the received code image istrusted based on a UID and a fingerprint stored inside a secure ROM ofthe device such as UID 119 and fingerprints 123 of FIG. 1. The chain ofcertifications may be performed based on a process similar to process600 at block 609 in FIG. 6. If the code image is successfully loaded andverified, in one embodiment, the state of the device may be transitionedfrom state Recovery2 719 to state Kernelcache 707.

During state iBoot 705, according to one embodiment, the device mayexecute the verified boot program to locate a kernel image such asKernelcache 233 shown in FIG. 2 within the device. The kernel image maybe located and loaded into a memory component of the device during stateiBoot 705. In one embodiment, the kernel image may be verified to be atrusted code image according to a process such as described at block 305of FIG. 3. If the kernel image is successfully located and verified,state 700 may enter state Kernelcache 707 from state iBoot 705.Otherwise, according to one embodiment, state 700 may enter stateRecovery3 721 as the device enters a DFU mode.

During state Recovery3 721, the device may be coupled with a hostcomputer to perform a recovery process such as shown in FIG. 5. In oneembodiment, the device may publish a status based on state Recovery3721. The host computer may send a code image corresponding to the statusreceived from the device at state Recovery3 721. In one embodiment, thecode image may be a kernel image such as Kernelcache 233 of FIG. 2. Thedevice may perform a chain of certifications to verify the received codeimage is trusted based on a UID and a fingerprint stored inside a secureROM of the device such as UID 119 and fingerprints 123 of FIG. 1. Thechain of certifications may be performed based on a process similar toprocess 600 at block 609 in FIG. 6. If the code image is successfullyloaded and verified, in one embodiment, the state of the device may betransitioned from state Recovery3 721 to state Kernelcache 707.

In one embodiment, during state Kernelcache 707, the device may executea verified kernel image to locate operating system components such as235 in FIG. 2. A located operating system component may be loaded into amemory component of the device to be verified as trusted according tothe execution of the verified kernel image during state Kernelcache 707.In one embodiment, the kernel image may determine whether an operatingsystem component is trusted according to a process such as described atblock 305 of FIG. 3. A privileged mode may be assigned to a trustedoperating system component based on the kernel image for accessinghardware level interface of the device, such as UID 119 or GID 121 ofFIG. 2. An operating system component without a signed signature may beassigned a user mode privilege during state Kernelcache 707. In oneembodiment, an operating system component may not be permitted to accesshardware level interface of the device. After the operation system issuccessfully loaded in to the memory of the device, state 700 maytransition from state Kernelcache 707 to state OS 709 corresponding to anormal operating environment. A user application may start running inassigned user mode during state OS 709. In one embodiment, a device atstate Kernelcache 707 may enter a DFU mode to receive a root image froma coupled host computer to restore or update operating system componentsfor the device.

FIG. 8 is a flow diagram illustrating one embodiment of a process tosecurely restore software components from a host to a device. Forexample, process 800 may be performed by systems as shown in FIGS. 1and/or 5. In one embodiment, the processing logic of process 800 mayconfigure the device as a boot device at block 801. A boot device may bein a DFU mode. A user may press a button of a device during a normalbooting of the device to configure the boot device into DFU mode. Theprocessing logic of process 800 may be activated intentionally by adevice user to repair damaged application software, to update oldapplication software, to install a firmware component or to manageexisting user data stored in the device. At block 803, according to oneembodiment, the processing logic of process 800 may establish a networkconnection with a host computer. The device and the host computer may beconnected through a network interface such as shown in FIG. 5. A restoresoftware, such as iTune from Apple Computer Inc., may be running on thehost computer to communicate with the device. The processing logic ofprocess 800 may publish a status to the host computer to identify thedevice as in a restore mode via the network connection at block 805. Adevice in a restore mode may also be in a DFU mode. In one embodiment,the status may include information such as device ID and/or product ID.The status may include an indication of required code images from thehost computer.

At block 807, according to one embodiment, the processing logic ofprocess 800 may receive boot images from the connected host computer.The boot images may include a boot loader such as LLB 229 or iBoot 231as shown in FIG. 2. In one embodiment, the boot images may include akernel cache such as Kernelcache 233 in FIG. 2. A boot image may bereceived based on the status published to the host computer at block805. In one embodiment, the boot images may be loaded into a memorycomponent of the device such as memory 103 of FIG. 1. The processinglogic of process 800 may receive a root image from the connected hostcomputer at block 809. A root image may be a RAM disk based on astripped down version of operating system for the device. In oneembodiment, the root image may include a restore application.

At block 811, according to one embodiment, the processing logic ofprocess 800 may receive a command from the connected host computer toexecute a received boot image. The boot image may be a boot loader. Inresponse, the processing logic of process 800 may verify the boot imageis trusted at block 813. In one embodiment, the processing logic ofprocess 800 may perform a process such as shown in FIG. 6 to determinewhether the boot image could be trusted based on a secure ROM chip suchas chip 105 in FIG. 1. In one embodiment, the processing logic ofprocess 800 may verify a Kernelcache received from the connected hostcomputer is trusted by executing a trusted boot image at block 815. Theprocessing logic of process 800 may perform a process such as shown inFIG. 6 to determine whether the Kernelcache could be trusted based on aroot certificate fingerprint stored in the device such as Fingerprints123 in FIG. 1. At block 817, the processing logic of process 800 mayverify a restore daemon application from the root image is trusted byexecuting the trusted Kernelcache. In on embodiment, the processinglogic of process 800 may determine the restore daemon application couldbe trusted by verifying the root image is a trusted code image. Theprocessing logic of process 800 may perform a process such as shown inFIG. 6 to determine whether the restore daemon application included inthe root image could be trusted.

At block 819, according to one embodiment, the processing logic ofprocess 800 may receive and execute commands calls from the hostcomputer via the restore daemon application to perform softwarerestoration operations. In one embodiment, software restorationoperations may include the partitioning and formatting of file systemsof mass storage, device level restoration or loading new firmware intothe device. The processing logic may start the OS included in the rootimage to launch the restore daemon in the device. In one embodiment,only the reduced portion or minimal portion of the OS is started. Thisdaemon application may communicate with the restore software running inthe connected host computer based on an XML (Extensible Markup Language)protocol. In one embodiment, the restore daemon may allow the restoresoftware running on the host computer to issue arbitrary commands to beexecuted by the device. The commands may include executing auxiliarytools included in the RAM disk and/or making library calls. In oneembodiment, the commands may cause replacing the entire set of softwarestored in the mass storage and the programmable ROM of the device. Atblock 821, the processing logic of process 800 may receive a commandfrom the connected host computer to restart the device. In response, theprocessing logic of process 800 may reset the device. Subsequently, thedevice may reboot from the operating system stored in the mass storageof the device.

FIG. 9 is a flow diagram illustrating one embodiment of a process tosecurely update an application from a host to a device. For example,process 900 may be performed by systems as shown in FIGS. 1 and/or 5.The processing logic of process 900 may establish a network connectionwith a host computer at block 901. The device and the host computer maybe connected through a network interface such as shown in FIG. 5. Updatesoftware, such as iTune from Apple Computer Inc., may be running on thehost computer to communicate with the device. The processing logic ofprocess 800 may publish a status to the host computer to identify thedevice as in an update mode via the network connection at block 803. Adevice in an update mode may also be in a DFU mode. In one embodiment,the status may include information such as device ID and/or product ID.The status may include an indication of a version ID of an applicationcurrently residing in the device.

At block 905, according to one embodiment, the processing logic ofprocess 900 may receive a code images from the connected host computer.The code image may include a software package related to an updatedversion of an application based on the version ID from the publishedstatus received by the host computer at block 903. In one embodiment,the code image may be loaded into a memory component of the device suchas memory 103 as shown in FIG. 1. At block 907, according to oneembodiment, the processing logic of process 900 may verify the codeimage is trusted. The processing logic of process 900 may perform aprocess such as shown in FIG. 6 to determine whether the code imagecould be trusted based on a fingerprint of a root certificate in asecure ROM chip such as Fingerprints 123 in chip 105 shown in FIG. 1. Inone embodiment, the processing logic of process 900 may execute theverified code image to unpack files from the included software packageand lay down those files inside the file system of the device at block909. A file from the software package may be a new file or an updatedversion of an existing file for the device. The processing logic ofprocess 900 may perform an integrity check against a file from thesoftware package to ensure the file is not compromised or corruptedbefore laying down the file into the file system of the device. In oneembodiment, the integrity of a file may be checked based on a signatureaccording to a hash on the file content. At block 911, the processinglogic of process 900 may reset the device to reboot from the operatingsystem stored inside the device.

FIG. 10 is a flow diagram illustrating one embodiment of a process ofexecuting unverified code image. For example, process 1000 may beperformed by a system as shown in FIG. 1. At block 1001, the processinglogic of process 1000 may disable access to a UID of a secure ROM in adevice such as UID 119 in FIG. 1. In one embodiment, a trusted codeimage may be configured to turn off access to the UID when executed. Inanother embodiment, a hardware switch of the device may include settingsthat turn off access to the UID. The access configuration of the UID maybe specified according to a diagnostic or testing requirement of thedevice. The trusted code image may be a boot image verified by codesinside a secure ROM of a device such as codes 115 in FIG. 1. In oneembodiment, the verification may be performed in a similar process asshown in FIG. 6. The boot image may be LLB 225 or iBoot 227 as shown inFIG. 2. At block 1003, the processing logic of process 1000 may load acode image into a memory component of the device such as RAM 111 ofFIG. 1. In one embodiment, the processing logic of process 1000 may loadthe code image based on a configuration of a trusted code imagecurrently being executed. The code image may be loaded from an externalnetwork connection or a mass storage coupled to the device. In oneembodiment, the code image may include diagnostic software for thedevice.

At block 1005, the processing logic of process 1000 may activate aprogramming interface to access device hardware by executing the codeimage. Device hardware may be accessed by reading or setting values ofdevice hardware parameters. The processing logic may derive a hash valuefrom the loaded code image to determine if the code image is notcompromised (e.g., not corrupted). The determination may be based on acomparison between the derived hash value and a header value from thecode image. In one embodiment, the processing logic of process 1000 maydetermine a UID is inactive at block 1007. The programming interface toaccess device hardware may cause an execution of codes inside a secureROM such as codes 115 in FIG. 1 for determining whether the UID isactive or not. At block 1009, the processing logic of process 1000continues executing the code image without accessing the devicehardware. In one embodiment, accessing to the device hardware may becontrolled by the codes inside a secure ROM of a device based on whetherthe associated UID is active or not. In another embodiment, user datamay not be accessible when a UID is not active. Even when an unverifiedapplication is loaded and executed in a device, no device hardware oruser sensitive data may be compromised if the LID is not active.

FIG. 11 shows one example of a data processing system which may be usedwith one embodiment the present invention. For example, the system 1100may be implemented including a host as shown in FIG. 5. Note that whileFIG. 11 illustrates various components of a computer system, it is notintended to represent any particular architecture or manner ofinterconnecting the components as such details are not germane to thepresent invention. It will also be appreciated that network computersand other data processing systems which have fewer components or perhapsmore components may also be used with the present invention.

As shown in FIG. 11, the computer system 1100, which is a form of a dataprocessing system, includes a bus 1103 which is coupled to amicroprocessor(s) 1105 and a ROM (Read Only Memory) 1107 and volatileRAM 1109 and a non-volatile memory 1111. The microprocessor 1105,coupled with cache 1104, may retrieve the instructions from the memories1107, 1109, 1111 and execute the instructions to perform operationsdescribed above. The bus 1103 interconnects these various componentstogether and also interconnects these components 1105, 1107, 1109, and1111 to a display controller and display device 1113 and to peripheraldevices such as input/output (I/O) devices which may be mice, keyboards,modems, network interfaces, printers and other devices which are wellknown in the art. Typically, the input/output devices 1115 are coupledto the system through input/output controllers 1117. The volatile RAM(Random Access Memory) 1109 is typically implemented as dynamic RAM(DRAM) which requires power continually in order to refresh or maintainthe data in the memory.

The mass storage 1111 is typically a magnetic hard drive or a magneticoptical drive or an optical drive or a DVD RAM or a flash memory orother types of memory systems which maintain data (e.g. large amounts ofdata) even after power is removed from the system. Typically, the massstorage 1111 will also be a random access memory although this is notrequired. While FIG. 11 shows that the mass storage 1111 is a localdevice coupled directly to the rest of the components in the dataprocessing system, it will be appreciated that the present invention mayutilize a non-volatile memory which is remote from the system, such as anetwork storage device which is coupled to the data processing systemthrough a network interface such as a modem, an Ethernet interface or awireless network. The bus 1103 may include one or more buses connectedto each other through various bridges, controllers and/or adapters as iswell known in the art.

FIG. 12 shows an example of another data processing system which may beused with one embodiment of the present invention. For example, system1200 may be implemented as part of system as shown in FIG. 1. The dataprocessing system 1200 shown in FIG. 12 includes a processing system1211, which may be one or more microprocessors or which may be a systemon a chip integrated circuit, and the system also includes memory 1201for storing data and programs for execution by the processing system.The system 1200 also includes an audio input/output subsystem 1205 whichmay include a microphone and a speaker for, for example, playing backmusic or providing telephone functionality through the speaker andmicrophone.

A display controller and display device 1207 provide a visual userinterface for the user; this digital interface may include a graphicaluser interface which is similar to that shown on a Macintosh computerwhen running OS X operating system software. The system 1200 alsoincludes one or more wireless transceivers 1203 to communicate withanother data processing system, such as the system 1100 of FIG. 11. Awireless transceiver may be a WiFi transceiver, an infrared transceiver,a Bluetooth transceiver, and/or a wireless cellular telephonytransceiver. It will be appreciated that additional components, notshown, may also be part of the system 1200 in certain embodiments, andin certain embodiments fewer components than shown in FIG. 12 may alsobe used in a data processing system.

The data processing system 1200 also includes one or more input devices1213 which are provided to allow a user to provide input to the system.These input devices may be a keypad or a keyboard or a touch panel or amulti touch panel. The data processing system 1200 also includes anoptional input/output device 1215 which may be a connector for a dock.It will be appreciated that one or more buses, not shown, may be used tointerconnect the various components as is well known in the art. Thedata processing system shown in FIG. 12 may be a handheld computer or apersonal digital assistant (PDA), or a cellular telephone with PDA likefunctionality, or a handheld computer which includes a cellulartelephone, or a media player, such as an iPod, or devices which combineaspects or functions of these devices, such as a media player combinedwith a PDA and a cellular telephone in one device. In other embodiments,the data processing system 1200 may be a network computer or an embeddedprocessing device within another device, or other types of dataprocessing systems which have fewer components or perhaps morecomponents than that shown in FIG. 12.

At least certain embodiments of the inventions may be part of a digitalmedia player, such as a portable music and/or video media player, whichmay include a media processing system to present the media, a storagedevice to store the media and may further include a radio frequency (RF)transceiver (e.g., an RF transceiver for a cellular telephone) coupledwith an antenna system and the media processing system. In certainembodiments, media stored on a remote storage device may be transmittedto the media player through the RF transceiver. The media may be, forexample, one or more of music or other audio, still pictures, or motionpictures.

The portable media player may include a media selection device, such asa click wheel input device on an iPod® or iPod Nano® media player fromApple Computer, Inc. of Cupertino, Calif., a touch screen input device,pushbutton device, movable pointing input device or other input device.The media selection device may be used to select the media stored on thestorage device and/or the remote storage device. The portable mediaplayer may, in at least certain embodiments, include a display devicewhich is coupled to the media processing system to display titles orother indicators of media being selected through the input device andbeing presented, either through a speaker or earphone(s), or on thedisplay device, or on both display device and a speaker or earphone(s).Examples of a portable media player are described in published U.S.patent application numbers 2003/0095096 and 2004/0224638, both of whichare incorporated herein by reference.

Portions of what was described above may be implemented with logiccircuitry such as a dedicated logic circuit or with a microcontroller orother form of processing core that executes program code instructions.Thus processes taught by the discussion above may be performed withprogram code such as machine-executable instructions that cause amachine that executes these instructions to perform certain functions.In this context, a “machine” may be a machine that converts intermediateform (or “abstract”) instructions into processor specific instructions(e.g., an abstract execution environment such as a “virtual machine”(e.g., a Java Virtual Machine), an interpreter, a Common LanguageRuntime, a high-level language virtual machine, etc.), and/or,electronic circuitry disposed on a semiconductor chip (e.g., “logiccircuitry” implemented with transistors) designed to executeinstructions such as a general-purpose processor and/or aspecial-purpose processor. Processes taught by the discussion above mayalso be performed by (in the alternative to a machine or in combinationwith a machine) electronic circuitry designed to perform the processes(or a portion thereof) without the execution of program code.

The present invention also relates to an apparatus for performing theoperations described herein. This apparatus may be specially constructedfor the required purpose, or it may comprise a general-purpose computerselectively activated or reconfigured by a computer program stored inthe computer. Such a computer program may be stored in a computerreadable storage medium, such as, but is not limited to, any type ofdisk including floppy disks, optical disks, CD-ROMs, andmagnetic-optical disks, read-only memories (ROMs), RAMs, EPROMs,EEPROMs, magnetic or optical cards, or any type of media suitable forstoring electronic instructions, and each coupled to a computer systembus.

A machine readable medium includes any mechanism for storing ortransmitting information in a form readable by a machine (e.g., acomputer). For example, a machine readable medium includes read onlymemory (“ROM”); random access memory (“RAM”); magnetic disk storagemedia; optical storage media; flash memory devices; electrical, optical,acoustical or other form of propagated signals (e.g., carrier waves,infrared signals, digital signals, etc.); etc.

An article of manufacture may be used to store program code. An articleof manufacture that stores program code may be embodied as, but is notlimited to, one or more memories (e.g., one or more flash memories,random access memories (static, dynamic or other)), optical disks,CD-ROMs, DVD ROMS, EPROMs, EEPROMs, magnetic or optical cards or othertype of machine-readable media suitable for storing electronicinstructions. Program code may also be downloaded from a remote computer(e.g., a server) to a requesting computer (e.g., a client) by way ofdata signals embodied in a propagation medium (e.g., via a communicationlink (e.g., a network connection)).

The preceding detailed descriptions are presented in terms of algorithmsand symbolic representations of operations on data bits within acomputer memory. These algorithmic descriptions and representations arethe tools used by those skilled in the data processing arts to mosteffectively convey the substance of their work to others skilled in theart. An algorithm is here, and generally, conceived to be aself-consistent sequence of operations leading to a desired result. Theoperations are those requiring physical manipulations of physicalquantities. Usually, though not necessarily, these quantities take theform of electrical or magnetic signals capable of being stored,transferred, combined, compared, and otherwise manipulated. It hasproven convenient at times, principally for reasons of common usage, torefer to these signals as bits values, elements, symbols, characters,terms, numbers, or the like.

It should be kept in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the above discussion, itis appreciated that throughout the description, discussions utilizingterms such as “processing” or “computing” or “calculating” or“determining” or “displaying” or the like, refer to the action andprocesses of a computer system, or similar electronic computing device,that manipulates and transforms data represented as physical(electronic) quantities within the computer system's registers andmemories into other data similarly represented as physical quantitieswithin the computer system memories or registers or other suchinformation storage, transmission or display devices.

The processes and displays presented herein are not inherently relatedto any particular computer or other apparatus. Various general-purposesystems may be used with programs in accordance with the teachingsherein, or it may prove convenient to construct a more specializedapparatus to perform the operations described. The required structurefor a variety of these systems will be evident from the descriptionbelow. In addition, the present invention is not described withreference to any particular programming language. It will be appreciatedthat a variety of programming languages may be used to implement theteachings of the invention as described herein.

The foregoing discussion merely describes some exemplary embodiments ofthe present invention. One skilled in the art will readily recognizefrom such discussion, the accompanying drawings and the claims thatvarious modifications can be made without departing from the spirit andscope of the invention.

1. A computer implemented method, comprising: verifying if a first codeimage is certified in a first booting state of a device for booting thedevice, the first code image stored in a storage of the device, whereinthe device transitions from the first booting state to a second bootingstate for booting the device if the first code image is certified; ifthe first code image is not certified, sending, in a third booting stateof the device, to a host over a communication link a status indicatingthe third booting state of the device, wherein the device transitionsfrom the first booting state to the third booting state for booting thedevice if the first code image is not certified; loading, subsequent tothe sending of the status, a code image from the host into the deviceover the communication link in the third booting state of the device,the code image digitally signed by a first signature; in response toreceiving a command to execute the code image from the host over thecommunication link in the third booting state of the device, determiningif the code image is certified by verifying the first signature using afingerprint embedded within a memory of the device, wherein the devicein the third booting state is controlled by the host and wherein thedevice transitions from the third booting state to the second bootingstate without reentering the first booting state for booting the deviceif the code image is certified; signing a second signature derived fromthe code image into a header of the code image if the code image iscertified according to the first signature; storing the certified codeimage including the header signed with the second signature in thestorage of the device, the certified code image replacing the first codeimage in the storage; and executing the certified code image in thesecond booting state of the device to establish an operating environmentof the device without reentering the first booting state of the device.2. The method of claim 1, wherein the executing comprises: determiningif the code image matches the first signature based on a public keycompatible with X.509 standard; and determining if the fingerprintmatches the public key, wherein the fingerprint is based on a hash valueof the public key.
 3. The method of claim 1, wherein the memory is a ROM(read only memory), and the method further comprising deriving a hashvalue from the certified code image; and encrypting the hash value intothe derived second signature based on a key stored in the ROM of thedevice, the key uniquely identifying the device.
 4. The method of claim1, wherein the code image is received from the host over thecommunication link in response to a failure of verifying codes initiallystored in the device in an attempt to establish the operatingenvironment of the device, and wherein the host receives the code imagefrom a server over a network.
 5. The method of claim 4, furthercomprising repairing the fail-to-verified codes initially stored in thedevice, such that subsequent operating environment can be establishedusing the repaired codes without having to involve the host.
 6. Themethod of claim 1, wherein the device is a portable device.
 7. Amachine-readable non-transitory storage medium having instructionsstored therein, which when executed by a machine, cause the machine toperform a method, the method comprising: verifying if a first code imageis certified in a first booting state of a device for booting thedevice, the first code image stored in a storage of the device, whereinthe device transitions from the first booting state to a second bootingstate for booting the device if the first code image is certified; ifthe first code image is not certified, sending, in a third booting stateof the device, to a host over a communication link a status indicatingthe third booting state of the device, wherein the device transitionsfrom the first booting state to the third booting state for booting thedevice if the first code image is not certified; loading, subsequent tothe sending of the status, a code image from the host into the deviceover the communication link in the third booting state of the device,the code image digitally signed by a first signature; in response toreceiving a command to execute the code image from the host over thecommunication link in the third booting state of the device, determiningif the code image is certified by verifying the first signature using afingerprint embedded within a memory of the device, wherein the devicein the third booting state is controlled by the host and wherein thedevice transitions from the third booting state to the second bootingstate without reentering the first booting state for booting the deviceif the code image is certified; signing a second signature derived fromthe code image into a header of the code image if the code image iscertified according to the first signature; storing the certified codeimage including the header signed with the second signature in a storageof the device, the certified code image replacing the first code imagein the storage; and executing the certified code image in the secondbooting state of the device to establish an operating environment of thedevice without reentering the first booting state of the device.
 8. Themachine-readable non-transitory storage medium of claim 7, wherein theexecuting comprises: determining if the code image matches the firstsignature based on a public key compatible with X.509 standard; anddetermining if the fingerprint matches the public key, wherein thefingerprint is based on a hash value of the public key.
 9. Themachine-readable non-transitory storage medium of claim 7, wherein thememory is a ROM (read only memory) and wherein the method furthercomprises deriving a hash value from the certified code image; andencrypting the hash value into the derived second signature based on akey stored in the ROM of the device, the key uniquely identifying thedevice.
 10. The machine-readable non-transitory storage medium of claim7, wherein the code image is received from the host over thecommunication link in response to a failure of verifying codes initiallystored in the device in an attempt to establish the operatingenvironment of the device, and wherein the host receives the code imagefrom a server over a network.
 11. The machine-readable non-transitorystorage medium of claim 10, wherein the method further comprisesrepairing the fail-to-verified codes initially stored in the device,such that subsequent operating environment can be established using therepaired codes without having to involve the host.
 12. Themachine-readable non-transitory storage medium of claim 7, wherein thedevice is a portable device.
 13. A digital processing system,comprising: a memory to store a fingerprint embedded therein; a massstorage; a main memory loaded with a code image received from a hostover a communication link, the code image digitally signed by a firstsignature; and a processor coupled to the memory, the mass storage, andthe main memory, the processor being configured to verify if a firstcode image is certified in a first booting state of the system forbooting the system, the first code image stored in the mass storage,wherein the system transitions from the first booting state to a secondbooting state for booting the system if the first code image iscertified; if the first code image is not certified, send to the hostover the communication link a status indicating a third booting state ofthe system, wherein the system transitions from the first booting stateto the third booting state for booting the system if the first codeimage is not certified, determine, in response to receiving a commandfrom the host over the communication link in the third booting state ofthe system, if the code image is certified according to the firstsignature using the fingerprint, wherein the system is controlled by thehost in the third booting state and wherein the system transitions fromthe third booting state to the second booting state without reenteringthe first booting state for booting the system if the code image iscertified, sign a second signature derived from the code image into aheader of the code image upon successfully verifying the code imageaccording to the first signature, store the certified code imageincluding the header signed with the second signature in the massstorage, the certified code image replacing the first code image in themass storage, and execute, in the second booting state of the system,the verified code image in the main memory to establish an operatingenvironment of the digital processing system without reentering thefirst booting state of the system.
 14. An apparatus, comprising: meansfor verifying if a first code image is certified in a first bootingstate of a device for booting the device, the first code image stored ina storage of the device, wherein the device transitions from the firstbooting state to a second booting state for booting the device if thefirst code image is certified; if the first code image is not certified,means for sending, in a third booting state of the device, to a hostover a communication link a status indicating the third booting state ofthe device, wherein the device transitions from the first booting stateto the third booting state for booting the device if the first codeimage is not certified; means for loading, subsequent to the sending ofthe status, a code image from the host into the device over thecommunication link in the third booting state of the device, the codeimage digitally signed by a first signature; means for, in response toreceiving a command to execute the code image from the host over thecommunication link in the third booting state of the device, determiningif the code image is certified by verifying the first signature using afingerprint embedded within ROM (read only memory) of the device,wherein the device in the third booting state is controlled by the hostand wherein the device transitions from the third booting state to thesecond booting state without reentering the first booting state forbooting the device if the code image is certified; means for signing asecond signature derived from the code image into a header of the codeimage if the code image is certified according to the first signature;means for storing the certified code image including the header signedwith the second signature in the storage of the device, the certifiedcode image replacing the first code image in the storage; and means forexecuting the certified code image in the second booting state of thedevice to establish an operating environment of the device withoutreentering the first booting state of the device.
 15. A computerimplemented method, comprising: in response to a failure of loading anexecutable image of a portable device in a first booting state of theportable device to boot the portable device, transitioning the devicefrom the first booting state to a second booting state as a recoverymode, wherein the device transitions from the first booting state to athird booting state of the portable device if the executable image issuccessfully loaded and wherein the portable device in the secondbooting state is controlled by a host coupled to the portable deviceover a communication link; communicating with the host via thecommunication link to signal that the device is in the recovery mode toreceive from the host a new executable image corresponding to the failedexecutable image; in response to receiving a command at the portabledevice in the second booting state from the host over the communicationlink, verifying the new executable image using a digital certificateembedded within a secure ROM of the portable device; upon successfullyverifying the new executable image, transitioning the portable devicefrom the second booting state to the third booting state withoutreentering the first booting state for booting the portable device;signing a signature derived from the verified new executable image intoa header of the verified new executable image; executing the verifiednew executable image in the third booting state of the portable devicefor booting the portable device without reentering the first bootingstate of the portable device; and storing the verified new executableimage including the derived signature as the header of the verified newexecutable image in a mass storage of the portable device, replacing thefailed executable image.
 16. The method of claim 15, further comprising:the host authenticating the portable device over the communication linkbased in part on the unique ID of the portable device; upon successfullyauthenticating the portable device, the host retrieving the newexecutable image from a server over a network; and delivering theretrieved new executable image to the portable device over thecommunication link.
 17. A computer implemented method, comprising: inresponse to successfully authenticating a portable device over acommunication link based in part on a unique identifier (ID) embeddedwithin a secure ROM (read-only memory) of the portable device,determining whether the portable device is in a recovery mode as aresult of a failure to certify a local code image for initializing anoperating environment of the portable device, wherein the determinationis based on a status received from the portable device over thecommunication link, the status indicating a booting state of theportable device for the initialization, wherein the portable devicecertified the local code image in a previous booting state of theportable device for the initialization, wherein the portable devicetransitioned from the previous booting state to the booting state viathe failure of the certification of the local code image, wherein theportable device includes a next booting state for the initialization,and wherein the portable device is capable of transitioning from theprevious booting state to the next booting state if the local code imagewas successfully certified; retrieving an executable image from a serverover a network, the executable image corresponding to the booting stateof the portable device indicated in the status, the executable imagebeing digitally signed by a signature if it is determined that theportable device is in the recovery mode; delivering the retrievedexecutable image to the portable device in the booting state for theinitialization over the communication link for controlling the portabledevice; and sending, subsequent to the delivery of the executable image,a command to execute the executable image over the communication link tothe portable device in the booting state, wherein the portable deviceverifies the signature of the executable image using a digitalcertificate embedded with the secure ROM, wherein the portable devicetransitions from the booting state to the next booting state withoutreentering the previous booting state for the initialization of theoperating environment if the executable image is successfully verified,wherein the portable device signs a signature derived from the verifiedexecutable image in a header of the verified executable image, whereinthe portable device stores the verified executable image including theheader signed with the derived signature in a storage of the portabledevice to replace the local code image in the storage, and wherein theverified executable image is loaded in a main memory of the portabledevice to establish the operating environment via the booting state ofthe portable device without reentering the previous booting state of theportable device.
 18. The method of claim 17, wherein the executableimage comprises data representing at least a kernel of an operatingsystem (OS) for the portable device, wherein the executable image, whichwhen executed by the portable device, establishes a virtual bootabledrive from which the at least the kernel of the OS is loaded in the mainmemory of the portable device.
 19. A machine-readable non-transitorystorage medium having instructions stored therein, which when executedby a machine, cause the machine to perform a method, the methodcomprising: in response to successfully authenticating a portable deviceover a communication link based in part on a unique identifier (ID)embedded within a secure ROM (read-only memory) of the portable device,determining whether the portable device is in a recovery mode as aresult of a failure to certify a local code image for initializing anoperating environment of the portable device wherein the determinationis based on a status received from the portable device over thecommunication link, the status indicating a booting state of theportable device for the initialization, wherein the portable devicecertified the local code image in a previous booting state of theportable device for the initialization, wherein the portable devicetransitioned from the previous booting state to the booting state viathe failure of the certification of the local code image, wherein theportable device includes a next booting state for the initialization,and wherein the portable device is capable of transitioning from theprevious booting state to the next booting state if the local code imagewas successfully certified; retrieving an executable image from a serverover a network, the executable image corresponding to the booting stateof the portable device indicated in the status, the executable imagebeing digitally signed by a signature if it is determined that theportable device is in the recovery mode; delivering the retrievedexecutable image to the portable device in the booting state for theinitialization over the communication link for controlling the portabledevice; and sending, subsequent to the delivery of the executable image,a command to execute the executable image over the communication link tothe portable device in the booting state, wherein the portable deviceverifies the signature of the executable image using a digitalcertificate embedded with the secure ROM, wherein the portable devicetransitions from the booting state to the next booting state withoutreentering the previous booting state for the initialization of theoperating environment if the executable image is successfully verified,wherein the portable device signs a signature derived from the verifiedexecutable image in a header of the verified executable image, whereinthe portable device stores the verified executable image including theheader signed with the derived signature in a storage of the portabledevice to replace the local code image in the storage, and wherein theverified executable image is loaded in a main memory of the portabledevice to establish the operating environment for the portable devicevia the booting state of the portable device without reentering theprevious booting state of the portable device.
 20. The machine-readablenon-transitory storage medium of claim 19, wherein the executable imagecomprises data representing at least a kernel of an operating system(OS) for the portable device, wherein the executable image, which whenexecuted by the portable device, establishes a virtual bootable drivefrom which the at least the kernel of the OS is loaded in the mainmemory of the portable device.